Ethernet is becoming the wired home-computer interconnect of choice, due to the low prices associated with its high-volume commodity components. Ethernet applications have been primarily limited to computer-to-computer or computer-to-I/O device connections. However, traditional or specialized links continue to be used for interconnecting consumer audio/visual (A/V) devices, due to the unpredictable worst-case delays associated with a conventional Ethernet connection.
The switched nature of Ethernet is attractive to the consumer-device environment, due to the possibility of dynamically specifying device connectivity based on the physical locations of the homeowner. However, to succeed in this environment, the latencies associated with Ethernet transfers must not be perceptible to humans.
The latency constraints of the RE supported time-sensitive traffic are therefore based on the delay-sensitivity of the human ear. To be comfortable when playing music, the delay between the instrument and the human ear should not exceed 10-to-15 ms. The individual hop delays must be considerably smaller, since instrument-sourced audio traffic may pass through multiple links and processing devices before reaching the ear.
To illustrate the per-hop latency requirements, consider RE components used for a home recording session. The audio inputs (microphone and guitar) might be converted, passed through a bridge, mixed within a laptop computer, converted at the speaker, and returned to the performer's ear through the air. If approximately ½ of a 15 ms delay budget is allocated to transfers over Ethernet links, the delay associated with each Ethernet link transfer must be less than 2 ms. Since each Ethernet transfer may pass through four (or so) bridges, the worst-case delay through each bridge must remain less than 0.5 ms.
The associated with transferring packets over Ethernet links are primarily caused by contention within the bridge for use of a common link for the transmission of multiple packets. The queue-contention delays within a bridge are typically much larger than the delays associated with electrical-signal propagation over the Ethernet link.
These numbers are only approximations; actual values (as determined by the marketplace) could vary substantially. For audio perfectionists, an overall processing latency of 5 ms may be desired; for discount shoppers, an overall latency of 15 ms may be acceptable. Ethernet networks could be tuned to reduce the number of hops through bridges, or ad-hoc networks of cascaded bridges could be present.
The acceptable worst-case delays must be guaranteed in the presence of unrelated computer-related traffic. The high data-transfer rates of disks and disk-array systems could easily exceed the bandwidth capacity of RE links, so some form of prioritized bridging is necessary to ensure robust delivery of time-sensitive A/V traffic.
Within the Internet, higher-layer protocols (such as the flow-control mechanisms of TCP) throttle the source to the bandwidth capabilities of the destination or intermediate interconnect. With the appropriate excess-traffic discards and rate-limiting recovery, such higher layer protocols can be effective in fairly distributing available bandwidth. For time-sensitive applications, however, the goal is to provide certain applications with bandwidth guarantees, not to distribute the available bandwidth fairly.
Over-provisioning is another technique for improving bandwidth guarantees. Over-provisioning involves using only a small portion of the available bandwidth, so that the cumulative bandwidth of multiple applications rarely exceeds that of the interconnect. This technique works well when occasional frame losses (due to occasional high-bandwidth bursts) are acceptable or when large numbers of traffic flows ensures a tight statistical bound for maximum bandwidth utilizations.
For most streaming applications within the home, however, over-provisioning is unacceptable. Even an occasional frame loss is unacceptable when listening to high-quality audio within the home. Also, frame losses are likely to be higher, since occasional traffic bursts (from computer-to-computer transfers, for example) will be likely, even though the average bandwidth consumption is low.
Prioritization is another technique for improving bandwidth guarantees. Existing networks assign priority levels to different classes of traffic, effectively ensuring delivery of one before delivery of the other. One could provide the highest priority to the video traffic (with large bandwidth requirements), a high priority to the audio traffic (lower bandwidth, but critical), and the lowest priority level to file transfers. A typical number of priorities is eight.
Strict priority protocols are deficient in that the priorities are statically assigned, and the assignments (based on traffic class) often do not correspond to the desires of the consumer. For example, priorities could result in transmission of two video streams, but not the audio associated with either.
Within computer systems, the transfer of time-sensitive packets has traditionally been supported on special-purpose interconnects, such as the IEEE Standard “IEEE Std 1394-1995 A High Performance Serial Bus”, or the industry standard Universal Serial Bus (USB). To avoid confusion with other serial buses (serial ATA, etc.), the term “SerialBus” is used to refer to this specific IEEE Std 1394-1995 standard.
Existing consumer equipment (digital camcorders, current generation high-definition, televisions (HDTVs), digital video cassette recorders (DVCRs), digital video disk (DVD) recorders, set top boxes (STBs), and computer equipment intended for media authoring) are designed to attach to the IEEE 1394 interconnect. A SerialBus system consists of multiple multi-port devices, one of which is selected to become the “root”. Other SerialBus devices are attached below the root, in a hierarchical fashion.
SerialBus is designed to emulate a bus, in that one and only one device, called the master, is allowed to transmit a packet at any time. To avoid concurrent transmissions, each packet transmission is preceded by an arbitration phase that selects the bus master for the following transmission. The arbitration phase involves sending arbitration requests towards the root, wherein the root device selects one of its requesting ports to be the “winner”. A arbitration grant is communicated through that port and is eventually forwarded to the attached device.
A leaf device is defined to be a device that has only one connection, and cannot therefore pass a grant through to another device. When a grant reaches such a leaf device, that device becomes the bus master and can transmit a queued packet.
SerialBus classifies packets as one of two types: asynchronous and isochronous. The isochronous packet types are used to transmit data whose delivery is time-sensitive. Time-sensitive data includes audio data being delivered to a speaker or headphones, when a human listener is present. If such data is delayed and cannot be presented at the scheduled time, an audible defect gap will be heard. The late delivery of time-sensitive data is therefore nearly equivalent to a loss of data and cannot be tolerated when listening to audio/visual data.
The timely delivery of SerialBus isochronous packet types is ensured by the nature of the arbitration protocols. Once every 125 microseconds, arbitration for asynchronous packet transmissions is inhibited. Arbitration then selects between masters with queued isochronous packets and allows those masters to transmit only their isochronous packets.
After all possible masters have transmitted their queued isochronous packets, no master is selected and an absence of arbitration grants (called an arbitration gap) occurs. This arbitration gap enables arbitration for asynchronous packet transmissions, which remain enabled until inhibited at the start of the next isochronous interval.
The SerialBus arbitration protocols are sufficient to ensure timely isochronous-packet deliveries in the presence of conflicting asynchronous traffic. However, these isochronous transfers could still fail if the offered load were allowed to exceed the link capacity. To eliminate this possibility, a SerialBus device is required to negotiate for use of sufficient isochronous-bandwidth resources before isochronous packets can be sent.
On simple topologies of less than 64 stations, SerialBus bandwidth reservations involve negotiations through a shared register. The initial value of this register is set to the fractional bandwidth dedicated to isochronous bandwidth transmissions. This fraction (typically approximately 75%) is intended support large amounts of time-sensitive traffic, without unduly compromising the ability to perform asynchronous transfers. Thus, a modest fraction of the bandwidth remains available to support non-time-sensitive transfers (such as computer-to-printer job transfers) as well as control (start, stop, and pause) of time-sensitive transfers.
A device can increase its isochronous bandwidth reservations by first detecting whether a sufficient amount remains in the account maintained within the bandwidth reservation register. If the amount indicated in the bandwidth-reservation register is sufficiently large, a device can increase its isochronous bandwidth reservations by subtracting the desired bandwidth amount from the bandwidth-reservation register. If the amount indicated in the bandwidth-reservation register is not sufficiently large, the request for additional isochronous bandwidth fails and an error is reported through a higher-level interface (such as an error message on a computer display or a blinking light on a consumer device).
Methods of accessing the bandwidth-reservation register are restricted to avoid corruption in the presence of simultaneous device accesses. Specifically, any change is required to be performed by using a compare&swap operation, which nullifies updates of the bandwidth-reservation register if its previously-read contents have changed. A device that detects such a nullification is expected to retry its changes to the bandwidth-reservation register. Since accesses of the bandwidth-reservation register are infrequent, only a few such retries are expected to occur.
The original SerialBus specification limits cable lengths to 4.5 meters, sufficient to support desktop device connections, although other physical layers support longer distances. With such short distances, the arbitration phase is a small portion of the 125 microsecond isochronous transmission cycle and this technique is relatively efficient. The longer-distance extensions to the SerialBus standard reduce such overheads by overlapping the arbitration and packet-transfer phases, but the lack of concurrent packet transmissions inherently limits its performance in large or long-distance topologies.
The SerialBus arbitration principles can not be easily adopted by Ethernet, since the arbitration overhead would be much larger due to the propagation delays associated with the 100 meter cables allowed by the Ethernet specification. For this and other reasons, most Ethernet systems no longer restrict concurrent packet transmissions, but allow each bridge to save incoming packets and then retransmit them when the corresponding outgoing links become available, a technique that is called store-and-forward. Within such store-and-forward based designs, the SerialBus arbitration methodology is no longer viable.
Another conventional design alternative for the transfer of time-sensitive packets is specified in the IEEE standard “IEEE Std 802.17-2004 Resilient packet ring (RPR) access method and physical layer specifications”. This standard will be called RPR. RPR is a metropolitan area network (MAN) that can be transparently bridged to Ethernet. The links between RPR stations are used to form a ring with up to 255 stations. All links on the ring operate at the same data rate, but may exhibit different delay properties. A ring circumference of less than 2,000 meters is assumed by the standard.
The RPR packet transmissions on one link are largely independent of frame transmissions on other link. Thus, distinct packets can be sent on the station1-to-station2 and station2-to-station3 links concurrently. Concurrent packet transmissions allow the overall packet-transmission bandwidths to exceed that of the individual links.
RPR provides transit queues, which allow a first station to receive packets from a second station while concurrently transmitting to a third station. The highest priority packets are classA and have their own transit queue; the lower priority frames are classB and classC, and share the use of a distinct transit buffer. To minimize the classA latencies, servicing of the classA transit queue has precedence over servicing of the classB/classC buffer.
The store-and-forward model allowed by RPR is closer to Ethernet than the broadcast-bus model assumed by SerialBus. RPR assumes the presence of bandwidth reservations, but only partially specifies how these reservations are managed. The higher-precedence classA traffic is delivered before classB/classC traffic, but bandwidth guarantees in the presence of conflicting classA traffic are not well specified.
While the special-purpose SerialBus, USB, and RPR interconnects have served a useful purpose, the wide-spread usage of Ethernet have successfully proliferated its presence from the data center to the home. Ethernet has become the wired home computer interconnect of choice, due to the low prices associated with its high-volume commodity applications. However, insufficient support of real-time services has limited Ethernet's success as a consumer audio-video interconnects.